Skip to content

fix(cache): disable setup-bun cache to avoid 5-retry HTML-error burn - #1259

Open
MukundaKatta wants to merge 1 commit into
anthropics:mainfrom
MukundaKatta:fix/setup-bun-cache-1252
Open

fix(cache): disable setup-bun cache to avoid 5-retry HTML-error burn#1259
MukundaKatta wants to merge 1 commit into
anthropics:mainfrom
MukundaKatta:fix/setup-bun-cache-1252

Conversation

@MukundaKatta

@MukundaKatta MukundaKatta commented Apr 26, 2026

Copy link
Copy Markdown

Why

Closes #1252.

anthropics/claude-code-action@v1's post-job cache save fails consistently on every second-and-subsequent run against the same PR ref. From the issue:

Attempt 1 of 5 failed with error: Unexpected token '<', "<!DOCTYPE "... is not valid JSON. Retrying request in 3000 ms...
Attempt 2 of 5 failed with error: Unexpected token '<', "<!DOCTYPE "... is not valid JSON. Retrying request in 5276 ms...
...
Warning: Failed to save: Failed to FinalizeCacheEntryUpload: Failed to make request after 5 attempts

Root cause: oven-sh/setup-bun@v2.2.0's post step calls @actions/cache.saveCache with a deterministic key derived from the Bun download URL (bun-<hash>). The key is identical across runs, so on every PR re-push the GitHub cache API rejects the duplicate key+ref with a 409 (HTML body). @actions/cache@5.x treats the unparsable response as transient and burns ~20-30s on 5 retries before surfacing a warning. The cache key isn't ref-aware and setup-bun doesn't expose a way to override it, so the issue is unavoidable as long as the cache is enabled.

This burns ~20-30s of wallclock per PR push after the first, plus persistent warning noise that masks real cache issues. See #1252 for the full repro and cache-entry inspection.

What

Pass no-cache: true to oven-sh/setup-bun in both action.yml and base-action/action.yml. The 35 MB Bun binary downloads from bun.sh in 2-3s on GitHub-hosted runners (curl install also relies on this in PR #819), so disabling the cache is a net wallclock win and removes the warning entirely.

This is the smallest action-side fix — alternatives would require either patching setup-bun upstream (issue author's option 2) or replacing it with curl-based install (issue author's option 4 / open PR #819, which targets a separate GHES bug).

Tested

Manual verification only — the change is YAML-only inside the composite step, and there are no unit tests for action.yml in test/ (tests cover TypeScript logic).

To verify after merge, run the action twice on the same PR ref and confirm:

  • The "Attempt 1 of 5 failed" warning no longer appears in the post-step.
  • The Install Bun step prints Downloading a new version of Bun on every run instead of Using a cached version of Bun.
  • Total Install Bun step time stays within a few seconds.

@MukundaKatta
fix(cache): disable setup-bun cache to avoid 5-retry HTML-error burn
8052091 
The upstream oven-sh/setup-bun action saves with a deterministic key
(Bun version) that isn't ref-aware. On every second-and-subsequent run
against the same PR ref, the GitHub cache API rejects the duplicate
key+ref with a 409 (HTML body), and @actions/cache treats the unparsable
response as transient and burns ~20-30s on 5 retries before warning.

The 35 MB Bun binary downloads in 2-3s, so disabling the cache is a net
wallclock win and removes the noisy warning that fires on every PR push
after the first.

Closes anthropics#1252
ndrc81
ndrc81 reviewed May 1, 2026
View reviewed changes

@ndrc81 ndrc81 left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approving this fix from a downstream-user perspective. We use claude-code-action@v1 in two workflows on a private repo (Claude Code Review and Adversarial Security Review), running on every PR per project policy. Each PR push burns approximately 5 minutes on the setup-bun post-step retries described in #1252, plus warning noise that masks real cache issues. At our current PR volume that pushes us to roughly 95% of the GitHub Team plan's 3000 min/month included allowance, with the burn entirely attributable to this bug.

The action-side fix here (no-cache: true on oven-sh/setup-bun) is the minimum-surface change and avoids the larger refactor of patching setup-bun upstream or migrating to a curl-based install. The 35 MB Bun binary downloads in 2-3s on GitHub-hosted runners, so the disabled-cache wallclock is a clear net win against the 20-30s of failing-retry burn on the current path. Confirming the YAML change is contained to the two action.yml files and does not change any TypeScript logic.

No additional regression risk we can identify. Strongly support merge.

@necofuryai

necofuryai commented Jul 26, 2026

Copy link
Copy Markdown

Reporting a second, independent failure mode that this PR also fixes.

We run claude-code-action from a Dependabot-triggered workflow_run job with
read-only permissions (untrusted PR content is analyzed there; writes are
isolated to a separate job). Per GitHub's documented cache policy,
workflow_run is a low-trust trigger that only gets read-only access to the
default branch's cache scope — so unlike the key collision in #1252 (second run
onward), this hits the first run too. In all 25 executions of our analysis
job to date, setup-bun's post step logged:

Cache reservation failed: cache write denied: token has no writable scopes
Failed to save: Unable to reserve cache with key bun-...

and restore missed in all 25 as well. The cache never provides value in this
configuration, so no-cache: true changes nothing for us except removing the
failed post-save and its warning. The only input that avoids it today is
path_to_bun_executable, which is documented as normally unnecessary and
version-sensitive.

Evidence: workflow · first run · latest run
(observed on v1.0.177/178; the setup-bun@v2.2.0 invocation is unchanged
through current main, so the behavior carries over).

One note: the branch currently conflicts with main (#1365 moved the setup-bun
pinning, and base-action/action.yml gets frequent version bumps), though the
fix itself remains the same two no-cache: true lines. @MukundaKatta if
rebasing is inconvenient, I'm happy to open a follow-up PR against current
main with credit and a link back here.

@necofuryai necofuryai mentioned this pull request Aug 1, 2026
Merged
@necofuryai

necofuryai commented Aug 1, 2026 •
edited
Loading

Copy link
Copy Markdown

I opened #1580 against current main as offered. It preserves @MukundaKatta's original commit authorship and links the additional downstream evidence from this thread. Happy to close it if #1259 is rebased instead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

1 more reviewer
@ndrc81 ndrc81 ndrc81 left review comments
Reviewers whose approvals may not affect merge requirements

At least 1 approving review is required to merge this pull request.

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Cache save fails with 5-retry HTML-error pattern on successive runs against the same PR ref (key+ref collision)

3 participants

@MukundaKatta @necofuryai @ndrc81